
\chapter{\textit{$\pi$SOD-M} Environment} 
\label{chap:environment}

\epigraph{``\textit{The computer was born to solve problems that did not exist
before.}''}{Bill Gates}

This chapter describes the $\pi$SOD-M environment for developing reliable
service based systems using the methodology we propose. The $\pi$SOD-M
environment is MDA-based and were developed to support the methodology
development. The process consists in generating an application starting from a \textit{$\pi$-UseCase} model and then transforming it into
series models of the PIM and PSM levels, and finally generating the code that implements the
application. 

%  that implements
% the generation of {\em Policy} based services' compositions. For a given
% services' based application, the process consists in generating an application
% starting from a $\pi$-UseCase modeling. From a $\pi$-UseCase model,
% transformations between models are made until the platform specific model level
% to generate service composition specification code. Four model to model
% transformations are performed, three transformations between models, and one
% model to text transformation generates the service composition specification in
% $\pi$-PEWS language. All transformations are done through an Eclipse plugin. All
% models definition are the result of a general process defined by the $\pi$SOD-M
% method in which a set of models are built following a service oriented approach. 
 
$\pi$SOD-M environment is built in the context of Eclipse framework
(http://www.eclipse.org), which is a framework to build Integrated Development
Environments (IDEs). We also use the Eclipse
Modelling Framework (EMF), a meta-modelling framework that was devised to be
extended and provides with the utilities needed to define, edit and handle
(meta)-models. To automate the transformation models we use the ATL Language
\cite{atl_manual}, a model transformation language framed in Eclipse.

ATL uses EMF to handle models, to serialize, to navigate and to modify them.
Once the ATL transformation is executed, the ATL engine matches the source
pattern and the source model and instantiates each pattern into the target model

% then for each matching, the target pattern is instantiated in the target model, replacing the match found in the
% source model.

% Thus, ATL works perfectly with the models defined over EMF, as well as
% $\pi$SOD-M plugin. So one, ATL compiler provides features like multiples source
% patterns, rule inheritance, and endpoint rules.

Another language used for model transformation is Acceleo \cite{acceleo}, a
model to text engine. $\pi$SOD-M uses this environment to generate service
composition specification code in \textit{$\pi$-PEWS} language.

%  After the user model the application and do the
% transformations, as final result, he can have the correspondent code for
% the service application. Thus, the methodology development environment
% is composed of these two platforms (ATL and Acceleo) that assist in the development
% of $\pi$SOD-M based applications.

% It is not necessary the methodology's final user knows Acceleo or ATL
% for modeling an application. These languages have been used only for the
% tools development. The tool's user also does not need have extensive knowledge
% in MDA to use the tool. Knowledge of basic MDA's concepts and what means
% transformation between models are sufficient to adapt and use the tool in a real
% development environment.
 
The remainder of the chapter is organized as follows. Section
\ref{sec:architecture}  we will describe the environment 
architecture and how it was developed, including meta-models definition, model
transformation process, and code generator engine. In section \ref{sec:install} we
describe how to install and use the environment, and finally, in section
\ref{sec:extendingEnvironment} we describe what is necessary to extend the
environment components.
 
\section{General Architecture}
\label{sec:architecture}

The $\pi$SOD-M environment architecture consist of components organized into
three layers: \textit{(i) EMF Ecore meta-model level, (ii) Model transformation
level} and (iii) \textit{Code generation level}.
 Each layer comprises a set of components that
together supports the development environment for $\pi$SOD-M methodology. The
main components are: \textit{(I)} - \textit{$\pi$-UseCase} ecore meta-model,
\textit{$\pi$-ServiceProcess} ecore meta-model,
\textit{$\pi$-ServiceComposition} ecore meta-model and
\textit{$\pi$-PEWS} ecore meta-model, that are
sub-components of the \textit{Meta-model component} (\textit{EMF Ecore
meta-model level}); \textit{(II)} - \textit{$\pi$-UseCase2$\pi$-ServiceProcess} component and
\textit{$\pi$-ServiceProcess2$\pi$-ServiceComposition} component, that are
sub-components of the \textit{PIM-to-PIM Transformation component} (\textit{Model transformation
level}); \textit{(III)} - \textit{$\pi$-ServiceComposition2$\pi$-PEWS}
component, that are sub-components of the \textit{PIM-to-PSM Transformation
component}; \textit{(IV)} - the \textit{Code Transformation} component
(\textit{Code generation level}); and \textit{(V)} - the \textit{Execution Engine} component, comprising both,
\textit{APolicy Engine} and \textit{PEWS Engine} components. Figure
\ref{fig:environmentComponents} presents how this set of components are
organized.

 
\begin{figure} [ht!]   
\centering
\includegraphics[width=1.0\textwidth]{chapters/implementation/figs/componentsWOE}
\caption{Environment Components} 
\label{fig:environmentComponents} 
\end{figure} 
  
The \textit{EMF Ecore meta-model level} comprises the components that describe
the $\pi$SOD-M meta-models, and how their models must be created. There are
four meta-models components. All components from \textit{Model
transformation level} depends of the definitions made in \textit{EMF Ecore meta-model level}.

When a model transformation is made, the models must comply with their
respective meta-model. The process is executed as follows, every time a
transformation is performed, a consistency check of both, source and target
models are realized. After all transformation be made, the PSM model is
translated into code of a particular platform, in the case of $\pi$SOD-M,
\textit{$\pi$-PEWS} is the chosen platform.  The transformation of PSM model in
code is the last stage of transformation. The component of the \textit{Code
generation level}  depend of the PSM model generated in the last model
transformation. Finally, the \textit{Execution Engine} component performs the
execution of the service-based specification code.

 
\begin{figure} [ht!]   
\centering
\includegraphics[width=1.0\textwidth]{chapters/methodology/figs/FrameworkOverviewFigure}
\caption{$\pi$SOD-M Development Environment.}
\label{fig:policymanager} 
\end{figure}  

Figure \ref{fig:policymanager} presents the general architecture for the
$\pi$SOD-M environment and detail how each component relate to each other, from
the most abstract level to the generation of the specification.

The following three sections will detail each particular feature of the
$\pi$SOD-M development environment.

 
\subsection{Ecore Meta-models}

The  \textit{EMF Ecore level} is a set of Ecore files that represents all
$\pi$SOD-M meta-model. These meta-models are the sources for the development of
each methodology's model. All models designed for a aaplication must obey the
meta-model specification. This level is composed of all the proposed methodology's models
in EMF (\textit{.ecore extension}), they are: \textit{$\pi$-UseCase,
$\pi$-ServiceProcess, $\pi$-ServiceComposition} and \textit{$\pi$-PEWS}.
 
% The Ecore Tools component provides a complete environment to create, edit and
% maintain Ecore models. This component eases handling of Ecore models with a
% Graphical Ecore Editor and bridges to other existing Ecore tools.  
% From a model specification, EMF provides tools and runtime support to produce a
% set of classes for the model, a set of adapter classes that enable viewing and
% command-based editing of the model, and a basic editor. Models can be specified
% using annotated UML, XML documents, or modeling tools, then imported into
% EMF. Most important of all, EMF provides the foundation for interoperability
% with other EMF-based tools and applications. 

% Although there are editors for each model of the methodology, it is still
% necessary components that can make a transformations between them. Thus the
% editing process need not be complete at all levels, but only at the highest
% level, \textit{i.e.} $\pi$-UseCase model, and then make automatic generation for
% the other models.

%After the creation of each meta-model were created their respective plugins.
 All meta-models have a related \textit{genmodel}\footnote{A .genmodel are
 automatically generated from the .ecore meta-model definition} definition. The
 plugin editor can be created from the \textit{genmodel} definition, so that
 models can be specified. The plugin editor supports the user to create models
 conform to the meta-model.

Thus, with these set of tools (model editors) it is possible to create models
at different $\pi$SOD-M levels. There are editors for all $\pi$SOD-M models:
\textit{$\pi$-UseCase editor, $\pi$-ServiceProcess editor,
$\pi$-ServiceComposition} editor and \textit{$\pi$-PEWS} editor.
 
Although there are editors for each methodology model, it is still
necessary components to perform transformations between them. Thus, the
model specification process can be made in all methodology levels. However it
can be made only at the highest level, \textit{i.e.} \textit{$\pi$-UseCase}
model, and then execute automatic transformation to generate lowest level
models.
 
 \subsection{Model Transformation}
 
 The \textit{Model transformation level} has a set of components for processing
 and transform models. The model transformation components are based on
 the source models for generating the equivalent target model. For example, from a \textit{$\pi$-UseCase} model is generated the
\textit{$\pi$-ServiceProcess} model, from a \textit{$\pi$-ServiceProcess}
model is generated the \textit{$\pi$-ServiceComposition} model, and finally,
from a \textit{$\pi$-ServiceComposition} model is generated a 
\textit{$\pi$-PEWS} model. After the model generation the
designer can perform any refinement. This can improve and adjust elements
that require a more detailed description in this modeling level.
% Figure \ref{fig:policymanager} shows the environment components for the
% processing models transformation. 


$\pi$SOD-M model transformation process is based on all rules described in
chapter \ref{chapter:methodology}. The implementation process were made considering several aspects and a strict sequence
for the right  matching of each model. We had to consider the Eclipse and ATL
environments for MDA-based application development, \textit{e.g.}, aspects of
(i) plugin generation; (ii) design model properties; (iii) compliance of the
designed meta-model with the generated model; (iv) the specific model
implementation; and so on.  Despite we need to consider some implementation
aspects, all the $\pi$SOD-M concepts, models and transformation rules were
obeyed. 



% \begin{itemize}
%   \item Each meta-model is modeled using the EMF environment. During the
%   meta-model definition, a beta plugin version was being generated to verify the
%   model development consistence and coherence. For example the $\pi$-UseCase
%   meta-model, during its definition, short use cases models examples were
%   developed to validate our definition;
%   \item A stable plugin version was generated and then a complete example was
%   modeled to validate the usability of each $\pi$SOD-M model plugin. The
%   sequence of the model plugin development were:
%   \textit{$\pi$-ServiceComposition, $\pi$-PEWS, $\pi$-UseCase} and
%   \textit{$\pi$-ServiceProcess}. We first generated the low level plugins to
%   validate the code generation from a service composition specification.
%   Immediately after we developed the high level model to the complete $\pi$SOD-M
%   support.  
%   \item  With all models well developed and assembled in the tool for each
%   aspect of service model development, it was necessary proceed with the
%   automatic transformation. Each transformation represents, from a specific
%   $\pi$SOD-M model, that it is possible to generate a equivalent lower level
%   $\pi$SOD-M model, \textit{e.g.}, (i) from the $\pi$-UseCase model, the
%   $\pi$-ServiceProcess can be generated; (ii) from the $\pi$-ServiceProcess
%   model a $\pi$-ServiceComposition can be generated; (iii) from the
%   $\pi$-ServiceComposition model, the $\pi$-PEWS model can be generated;  and
%   (iv) from the $\pi$-PEWS model, the system service composition code can be
%   generated.
%   \item By the end, we configure a $\pi$SOD-M Eclipse version for research use.
% \end{itemize}  

We used the Eclipse Modeling Framework (EMF) for implementing the
meta-models  \textit{$\pi$-UseCase, $\pi$-ServiceProcess,
$\pi$-ServiceComposition} and \textit{$\pi$-PEWS}. The ATL language were used
for developing the mapping rules for transformation of models
(\textit{$\pi$-UseCase2$\pi$-ServiceProcess},
\textit{$\pi$-ServiceProcess2$\pi$-ServiceComposition} and
\textit{$\pi$-ServiceComposition2$\pi$-PEWS}) plug-ins. And we used Acceleo for
implementing  the code generation plug-in. We coded the \textit{pews.mt} program
that implements the model to text transformation for generating executable code.
It takes as input a \textit{$\pi$-PEWS} model implementing a specific service
composition and it generates the code to be executed by the {\em Policy} based
\textit{Execution Engine} (figure \ref{fig:environmentComponents}).


 \begin{figure}  [ht!]
\centering 
\includegraphics[width=1.0\textwidth]{chapters/methodology/figs/modelTrasformation}
\caption{ATL Model to Model Transformation in $\pi$SOD-M.}
\label{fig:modelTomodelTransfomation}
\end{figure} 
  

 Figures \ref{fig:modelTomodelTransfomation} and 
 \ref{fig:modelToTextTransformation} present a general view of the $\pi$SOD-M
 models transformation, showing the set of plug-ins developed in order to
 implement it. The environment implements the abstract architecture shown in
 figure \ref{fig:policymanager}. Thus, it consists of plug-ins implementing the
 \textit{$\pi$-UseCase, $\pi$-ServiceProcess, $\pi$-ServiceComposition} and
 \textit{$\pi$-PEWS} meta-models used for defining models; and ATL rules for
 transforming PIM and PSM models (model to model transformation) and finally generating code (model to text
 transformation) with Acceleo.
 
 
\begin{figure} [ht!]  
\centering
\includegraphics[width=0.7\textwidth]{chapters/methodology/figs/AcceleoTransformationFigure}
\caption{Acceleo Model to Text Transformation in $\pi$SOD-M.}
\label{fig:modelToTextTransformation}
\end{figure}  


To proceed with a model transformation is necessary to configure the
transformation environment. Figure \ref{fig:configurationATL} presents a
standard screen for configuration of each transformation. From any source model,
for example, \textit{$\pi$-UseCase, $\pi$-ServiceProcess} or
\textit{$\pi$-ServiceComposition}, it can perform the automatic transformation.
Therewith it is necessary to choose the model to be transformed\footnote{selecting the following option:  Run > Run
As > ATL Transformation}. It requires: (i) indicate the
transformation rules file; (ii) choose the source meta-model reference; (iii)
choose the target meta-model reference; (iv)  choose the source model
that will be transformed; (v)  choose the target model name
that will be generated; and finally, (vi) the user must proceed with the
transformation.


\begin{figure}[ht!]
\centering
\includegraphics[width=.90\textwidth]{chapters/implementation/figs/ATL-trasnformationPiUseCase2PiServiceProcess.pdf}
\caption{ATL Configuration for $\pi$SOD-M Transformation.}
\label{fig:configurationATL}
\end{figure}


As an example, figure \ref{fig:configurationATL} shows the configuration for the
transformation from \textit{$\pi$-UseCase} (source) to
\textit{$\pi$-ServiceProcess} (target). Thus, the reference meta-models must be the same. For further
transformation, this process must follow the same sequence, changing only the
models and reference meta-models.

\subsubsection{\textit{$\pi$-UseCase2$\pi$ServiceProcess} Transformation Rules}

The transformation rules describe how models are transformed according to
the particularity of each one. The automatic transformation of
models favors a faster development of applications, however the environment or
the designer should verify if the transformations are valid or not. This
verification can be performed automatically or manually. In the $\pi$SOD-M
environment, the consistency of the transformations must be performed by the
designer. If any transformation is not completely satisfied, the target model
can be modified manually.

The rules for automatic \textit{$\pi$-UseCase2$\pi$ServiceProcess}
transformation comply with the description made in section
\ref{sec:models-tranformation}, and we present some rules in ATL for model
transformation in $\pi$SOD-M. We present the main ATL rules used to implement
the model transformation.



\begin{figure}
\tiny
\centering

\begin{lstlisting}[label=list:useCase2Action,caption=ATL -
piUseCase2piServiceProcess : useCase2action Rule ]

1  rule useCase2action {
2  	 from usecase : PiUseCase!FunctionalBasicUseCase(		
3   	 usecase.extend->size() >= 2	
4  	 )
5  	 to sp_action :  PiServiceProcess!Action (
6		  name <- usecase.name
7	 ), sp_serviceActivity : PiServiceProcess!ServiceActivity(
8		 action <- sp_action,
9		 name <- usecase.name + 'SA',
10		 serviceProcess <- thisModule.raiz_piUseCase
11	 ), sp_contract: PiServiceProcess!Contract(					
12		 name <- usecase.name + 'Contract',
13		 assertionInContract <- usecase.UCContraint,
14		 action <- sp_action,
15		 serviceProcess <- thisModule.raiz_piUseCase
16	 ) 	
17 }
\end{lstlisting}
\label{fig:pewscontract} 
\end{figure}   


\begin{figure}
\tiny
\centering

\begin{lstlisting}[label=list:constraint2contract,caption=ATL -
piUseCase2piServiceProcess : constraint2contract Rule ]

1  rule constraint2contract{	 
2	  from		
3		  constraint: PiUseCase!UseCaseConstraint
4	  to
5		  assertion: PiServiceProcess!Assertion(
6			  name <- constraint.name,
7			  description <- constraint.description	
8		  )
9  }
\end{lstlisting}
\label{fig:pewscontract} 
\end{figure}   

Listing \ref{list:useCase2Action} shows the ATL transformation rule between a
{\sc Use Case} and an {\sc Action}, while listing \ref{list:constraint2contract}
shows the transformation rule between {\sc Constraint} and {\sc Assertion}.
There is a restriction in the rule presented in listing
\ref{list:useCase2Action} (line 3), which defines that there must be more than
two {\sc Extend} relation between use cases. In this case, all use cases are
transformed into actions, and are grouped into a {\sc Service Activity} (lines
7-10). And all the constraints are transformed in a set of assertions that are
automatically associated with a {\sc Contract} (lines 11-15). The listing
\ref{list:constraint2contract} describes that all constraint are directly
transformed into an assertion (there is no restriction in the this clause). The
restrictions are treated in separate rules such as in listing
\ref{list:useCase2Action}.

\subsubsection{\textit{$\pi$-ServiceProcess2$\pi$-ServiceComposition}
Transformation Rules} 

As the \textit{$\pi$-ServiceComposition} model is a
refinement of some concepts defined in \textit{$\pi$-ServiceProcess}, such as 
{\sc Contract} and {\sc Activity Services}, most of the transformation
between these models is through direct transformation, without restrictions.
This is due to the fact that most of the the meta-model entities are identical.
Thus, we present the ATL transformation (listing
\ref{list:rooServiceProcess2rootServiceComposition}) of the root element that
comprises the main elements of both models. 


\begin{figure}
\tiny
\centering

\begin{lstlisting}[label=list:rooServiceProcess2rootServiceComposition,caption=ATL -
piServiceProcess2piServiceComposition : root Rule ]

1  rule root {
2 	from		
3 		root: piServiceProcess!ServiceProcess
4	to
5		root_service: piServiceComposition!CompositionServiceModel(
6			activities <- root.activity,
7			edges <- root.edge,
8			compositionPolices <- root.contract
9		)
10 }

\end{lstlisting} 
\label{fig:pewscontract} 
\end{figure}

Listing \ref{list:rooServiceProcess2rootServiceComposition} shows the
transformation rule for the main elements from \textit{$\pi$-ServiceProcess} 
to \textit{$\pi$-ServiceComposition} model. The {\sc Activities} and its
{\sc Edges}, and {\sc Contracts}, which are transformed into {\sc Policy} (lines
6-8). Other rules that describe the transformation between {\sc Assertions} into
policy {\sc Rule} are other type of transformation. However, other rules
describes that all {\sc Contracts} must belong to a specific {\sc Non-functional
Requirement}, for example, all contracts for the performance restrictions, will
be grouped into a single  performance {\sc Policy}. This listing is an ATL
example for \textit{$\pi$-ServiceProcess} model transformation into 
to \textit{$\pi$-ServiceComposition} model.

\subsubsection{\textit{$\pi$-ServiceComposition2$\pi$-PEWS} Transformation
Rules}

The transformation \textit{$\pi$-ServiceComposition2$\pi$-PEWS} is
unique among PIM and PSM levels, however there is no difference in the
rules description in ATL, since all rules are defined in terms of
meta-models rather than specific models. Thus, PIM-to-PSM transformation rules
in ATL follow the same syntax and semantics of the PIM-to-PIM transformation
rules.

The model to be generated in this transformation, namely \textit{$\pi$-PEWS}
model, will be used as input for the code generation component, so that the
application code specification is generated. We present two rules transformation
in listings \ref{list:rootSC2PEWS} and \ref{list:rulePre}. 


\begin{figure} 
\tiny
\centering

\begin{lstlisting}[label=list:rootSC2PEWS,caption=ATL -
piServiceComposition2piPEWS : root Rule ]

1  rule root{ 
2	 from sCM : pisc!CompositionServiceModel
3	 to 
4	 	path: pipews!Path (),
5	 	pews : pipews!PEWSCTSpec (
6			name <- 'newModelPEWSpecName',
7			has <- path,
8			contains <- sCM.partition,
9			defines <- 	thisModule.policies
10		)
11  }
\end{lstlisting}
\label{fig:pewscontract} 
\end{figure}   
\begin{figure}
\tiny
\centering

\begin{lstlisting}[label=list:rulePre,caption=ATL -
piServiceComposition2piPEWS : Pre-condition Rule ]

1  rule rulePre{
2 	 from
3		r: pisc!Rule (
4			r.event = #PRE)
5	 to
6		rAct: pipews!Action(
7			act <- r.action
8		),
9		rEvt: pipews!Event( 
10			type <- #ActivityPrepered
11		),
12		rCond: pipews!Condition(
13			expression <- r.condition
14		),
15		rRule: pipews!Precondition(			
16			calls <- rAct,
17			defines <- rCond,
18			hasSome <- rEvt,
19			policy <- r.policy
20		)
21  }

\end{lstlisting}
\label{fig:pewscontract} 
\end{figure}

The listings \ref{list:rootSC2PEWS} and \ref{list:rulePre} present two
transformation rules in ATL. The first describes the transformations of the main
elements for the description of a service composition, the main path, the name
of the specification, the services and policies (lines 6 - 9), while
listing \ref{list:rulePre} describes a policy {\sc Rule} and its related concepts, such as
{\sc Action}, {\sc Event} and {\sc Condition}. The ATL rule has a constraint
to be checked (line 4), what kind of {\sc Rule} is being translated for the
specific language, because depending on the type, the transformation will be
change. The {\sc Rule} element (line 15) consists of all the properties necessary to
create a {\sc Pre-condition}, such as {\sc Action}, {\sc Event} and {\sc Condition} (lines 16-18),
and to which {\sc Policy} the {\sc Pre-condition} is related (line 19).

The next section will show how the code is generated from a \textit{$\pi$-PEWS}
model.

\subsection{Code Generation}
 
The $\pi$SOD-M architecture's code generation component (\textit{\textit{Code
generation level}}) is a \textit{$\pi$-PEWS} specification generator. The
code is produced from a \textit{$\pi$-PEWS} model, after it be generated by a
model transformation from \textit{$\pi$-ServiceComposition} model. This
component was implemented using Acceleo \cite{acceleo}.   


\begin{figure}[ht!]
\centering
\includegraphics[width=1.0\textwidth]{chapters/implementation/figs/codeGeneration.pdf}
\caption{Acceleo Specification for \textit{$\pi$-PEWS} Code Generation.}
\label{fig:acceleoCode}
\end{figure}

Figure \ref{fig:acceleoCode} presents the \textit{$\pi$-PEWS} meta-model
developed using EMF and some pieces of Acceleo specification. This figure shows
the specification for the \textit{Namescape, Operation, Service} and
\textit{Contract} code generation for \textit{$\pi$-PEWS}. After the code
transformation process, a \textit{.pews} file is created. The listing
\ref{list:namespace}, \ref{list:service} and \ref{list:contract} present parts of Acceleo code for the \textit{$\pi$-PEWS} code generation. The code are the same presented in figure
\ref{fig:acceleoCode}, which presents the relation between the meta-model
concepts and the Acceleo code. The code generation follow the language syntax
described in appendix \ref{append:pews_language}.


     
\begin{figure}
\tiny
\centering

\begin{lstlisting}[label=list:namespace,caption=Acceleo - Namespace and
Operation Code Specification] 
1  <%script type="PiPEWSMetamodel.PEWSSpec" name="default"
2  file="<%name%>.pews"%>
3  //-----------------------------------------------------------------
4  //------------ <%name%>.pews Service Specification ----------------
5  //-----------------------------------------------------------------

7  //Namespaces
8  <%for (contains){%>
9    namespace <%name%> = <%WDSLAdress%>
10  <%}%>

12  //Operations
13  <%for (has.eAllContents("Operation")){%>
14    alias <%alias%> = portType/<%name%> in <%isDefinedIn.name%> 
15  <%}%>
\end{lstlisting}
\label{fig:pewscontract} 
\end{figure}   


In listing \ref{list:namespace} (lines 1-2) references the 
meta-model (\textit{PiPEWSMetamodel}), the root element (\textit{PEWSSpec}), and the
name of the generated file (\textit{<\%name\%>.pews}). Lines 3-5 presents the
name of the service specification. Lines 7-10 describes a \textit{for}
integration in the \textit{contains} relationship between \textit{PEWSSpec} and
\textit{Namespace}, and lines 12-15 all operations defined in each
\textit{Namespace} is generated. This operations came from the
\textit{isDefinedIn} relationship between \textit{Namespace} and
\textit{Operation} entities.

\begin{figure}
\tiny
\centering

\begin{lstlisting}[label=list:service,caption=Acceleo - Service Code
Specification] 
1   //Services
2   <%for (has.eAllContents("CompositeOperation")) {%>	
3     service <%name%> = <%contains.left.filter("Operation").alias%> 
4     <%if ((contains.nameOperator.toString().equalsIgnoreCase("sequence"))) {%> 
5         . 
6     <%}else if((contains.nameOperator.toString().equalsIgnoreCase("parallel"))){%> 
7         || 
8     <%}%> 
9    <%contains.right.filter("Operation").alias%>
10  <%}%>
\end{lstlisting}
\label{fig:pewscontract} 
\end{figure}     

Listing \ref{list:service} presents the Acceleo specification for the
\textit{$\pi$-PEWS} model transformation into code. A service is an alias for
one or more operations. Listing \ref{list:contract} specifies the contract generation, using the
\textit{defines} relationship between \textit{APolicy} and \textit{Rule}. Each
contract have a set o rules for the specification. 
 
\begin{figure}
\tiny
\centering

\begin{lstlisting}[label=list:contract,caption=Acceleo - PEWS Contract
Code Specification] <%script type="PEWSMetamodel.PEWSCTSpec" 
1  //Contract
2  <%for (defines) {%>	
3  defContract <%name%>Contract{
4	 isAppliedTo: <%isRelatedWith.filter("Operation").alias%>;
5	 <%for (defines.filter("Precondition")) {%>
6	 requires: <%defines.expression%>
7  		(OnFailureDo: <%calls.act.toString()%>);
8	 <%}%>
9	 <%for (defines.filter("Postcondition")) {%>
10	 ensures: <%defines.expression%>
11 		(OnFailureDo: <%calls.act.toString()%>); 
12	 <%}%>
13	 <%for (defines.filter("TimeRestriction")) {%>
14	 timeConstraints: <%defines.expression%>
15	 <%}%>
16 }	
	
 <%}%>
\end{lstlisting}
\label{fig:pewscontract} 
\end{figure}   

After the code generation, it can be executed in both, \textit{$\pi$-PEWS} and
A-Policy engine, however these 2 engines are not native components in the
$\pi$SOD-M plugin. The environment supports the process design until the
equivalent code generation. New language editor components, like BPEL or XAML, can be easily
coupled in the environment. Therewith, it is necessary add the language
meta-model and make the transformation process. Thus, from a
\textit{$\pi$-ServiceComposition} model, different models and codes can be
generated, not only \textit{$\pi$-PEWS}. The code generation can be done for any
service composition language. This requires only the equivalent meta-models, and their
code transformation rules.
 
The composition engine manages the life cycle of the composition. Once a
composition instance is activated, the engine schedules the composition
activities according to the composition control flow. Each activity is seen as
the process where the service method call is executed. The execution of an
activity has four states: prepared, started, terminated, and failure. The
execution of the control flow (sequence, and/or split and join) can also be
prepared, started, terminated and raise a failure.

At execution time, the evaluation of policies done by the {\em Policy} manager
must be synchronized with the execution of the services' composition (i.e., the
execution of an activity or a control flow).  Policies associated to a scope are
activated when the execution of its scope starts. A {\em Policy} will have to
be executed only if one or several of its rules is triggered. If several rules
are triggered the {\em Policy} manager first builds an execution plan that
specifies the order in which such rules will be executed according to the
strategies defined in the following section.        
%Once rules have been executed, the {\em A-policy} finishes its execution and returns to a sleeping state.
If rules belonging to several policies are triggered then policies are also
ordered according to an execution plan. The execution of policies is out of the
scope of this paper, the interested reader can refer to
\cite{Espinosa-Oviedo2011a} for further details. 


Figure \ref{fig:sequenceDiagram} presents a sequence diagram describing the
 model transformation process and how the designer interacts with the
 environment to specify each $pi$SOD-M model until the specification code be generated. 
 
 The next section will describe how the creation and generation of each model in
 SOD-M  is done, for better understanding the transformations process
 represented in figure \ref{fig:sequenceDiagram} .   


\section{Defining Reliable Service Based Applications}
\label{sec:install}
 
The SOD-M environment\footnote{The environment download
can be performed at http://www3.ifrn.edu.br/\~placido/piSOD-M} development
starts with the creation of a project and then the definition of a
\textit{$\pi$-UseCase} model\footnote{To create a model, the user must execute the sequence: \textit{File > New
> Other > EMF Model Wizard}, and choose one of the methodology's model.}, supposing that the business and requirement
specification document have been previously completed.

 Figure \ref{fig:screanPiSODM} presents the views provided by the environment:
 \textit{Project view, Menu view, Editor view} and \textit{Properties view}. 

% As $\pi$SOD-M environment is based on Eclipse, the developer and analyst
% need not struggle to adapt to the modeling environment. Figure
% \ref{fig:screanPiSODM} presents a tool overview, which has four views:

 

\begin{figure}[ht!]

\includegraphics[width=.99\textwidth]{chapters/implementation/figs/telaPiSOD-M.pdf}
\caption{$\pi$SOD-M Eclipse Plugin Environment.}
\label{fig:screanPiSODM}
\end{figure}


\begin{landscape}
\begin{figure}
\includegraphics[width=25cm,height=15cm]{chapters/implementation/figs/sequenceDiagram.pdf}
\caption{Model Transformation Process.}
\label{fig:sequenceDiagram}
\end{figure}
\end{landscape}


% For editing is important to follow the concepts presented in $\pi$SOD-M
% meta-models, because it must follow rigorously its structure.

\subsection{\textit{$\pi$-UseCase} Model} 

The goal of creating a \textit{$\pi$-UseCase} is to represent the functions and
system services described in the requirements specification and
business specification documents, which are the requirements input for this
phase. Figure \ref{fig:sequenceDiagram} depicts the designer receives the
documents as input and from them creates the \textit{$\pi$-UseCase} model. With the
model created, the transformation component generates the
\textit{$\pi$-ServiceProcess} model as output.

 To create the \textit{$\pi$-UseCase} model, it is necessary
choose the root element (\textit{Model}) as the starting point of modeling,
during the process of create a ``\textit{new .piusecase file}'' (
using the sequence, \textit{File > New > Other > EMF Model Wizard}). From
this point the model is created a tree of elements with its specific references,
as shown in Figure \ref{fig:pisodmToolModel}, which shows the model elements and its equivalence in the graphical $\pi$-UseCase
model, each element is built in an iterative way and must obey the hierarchy
and its relationships.

Each model element has a number of child or sibling that is related to,
\textit{e.g.}, an {\sc Use Case} relates {\sc Constraint}, {\sc Extend} and
{\sc Include} elements, as well as {\sc NFRs} relates {\sc NFAs}.
Figure \ref{fig:pisodmToolModel} shows how to create the model elements. 

Items 1 and 2 in Figure \ref{fig:pisodmToolModel} show how to create an
{\sc Actor} and a {\sc Requirement}, item 3 presents the \textit{update music}
{\sc Use Case} and how to create a {\sc Constraint} related to this element.
Item 4 makes reference to a {\sc Constraint} and finally, the items 5 and 6 are
equivalent to a {\sc NFR} and a {\sc Package} elements, respectively. Each item
in the model refers to a equivalent element in the graphical model.


\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/implementation/figs/create_model-UseCase.pdf}
\caption{$\pi$-UseCase Model Definition in $\pi$SOD-M Eclipse Plugin.}
\label{fig:pisodmToolModel}
\end{figure}

Figure \ref{fig:pisodmToolModelProperties} presents some configuration
properties. After creating an element, it is necessary to set its properties.
All elements have properties the describes its relationship and specification
values. These properties are used to give specification details, as
well to future transformations. 

% All properties must be set, except of the
% properties are not used in the specification of one specific application, for
% example, there is no exceptional behaviour for an action. In this case it is not
% necessary to set this property. Another example that is no necessary set a
% element property is an actor or use case are not related with a package.

Item 1 in Figure \ref{fig:pisodmToolModelProperties} shows the {\sc Use Case}
element properties. After its creation is needed to describe the
\textit{actor} is related to this \textit{use case}, its \textit{name}, which
\textit{requirement} the \textit{use case} belongs, and the respective \textit{package}. 
Item 2 shows the properties of a {\sc Constraint} element. In a
constraint, its type must be explicit (\textit{VALUE, BUSINESS} or
\textit{EXCEPTIONALBEHAVIOUR}), its \textit{description}, with all candidate
\textit{variables} described with an `\textit{@}', its \textit{name} and which
{\sc Non-Functional Attributes} element this constraint is related to,
\textit{e.g.}, \textit{Authentication}, is an attribute of the
{\sc Non-Functional Requirements}, \textit{Security}. Items 3 and 4 show the
 ``\textit{To Publish Music}'' requirement properties and package
``\textit{app}'', respectively. The properties of each element obey the elements
described in the \textit{$\pi$-UseCase} meta-model. 


\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/implementation/figs/model-UseCase.pdf}
\caption{\textit{$\pi$-UseCase} Properties in $\pi$SOD-M Eclipse Plugin.}
\label{fig:pisodmToolModelProperties}
\end{figure}

\subsection{\textit{$\pi$-ServiceProcess} Models}

The goal of creating a \textit{$\pi$-ServiceProcess} model is to represent the
system execution flow. The designer receives the
\textit{$\pi$-UseCase} model as input to generate the
\textit{$\pi$-ServiceProcess} model. After the \textit{$\pi$-ServiceProcess}
model be generated, the designer calls again the model transformation component
to generate the \textit{$\pi$-ServiceComposition} model as output (figure
\ref{fig:sequenceDiagram}).

 To create the \textit{$\pi$-ServiceProcess} model, it is necessary
choose the root object (\textit{Service Process}) as the starting point of
modeling, during the process of create a ``\textit{new .piserviceprocess file}''
option. From this point the model is created as a tree with its specific
references.

%  Figure \ref{fig:piserviceProcessToolModel} 
% presents the service process model, a graphical model reference and detail of
% how create each model element. It is possible to create the $\pi$-ServiceProcess
% model in isolation, however this model is generated from the previous model
% descriptions.

As this model is a refinement of the concepts described in the previous model, many information are part of the information
and properties of the \textit{$\pi$-UseCase} model, however with the focus on
the process workflow and application implementing functions. Figure \ref{fig:piserviceProcessToolModel}
shows the complete model of the example scenario and its main components. From
the root element the user can create the following elements: {\sc Service
Activity, Object Flow, Control Flow, Contract} and {\sc Non-Functional
Attribute}. 

In Figure \ref{fig:piserviceProcessToolModel}, item 1  highlights the creation
of the {\sc Control Flow } element, items 2 and 3 show the elements {\sc Fork
Node} and {\sc Join Node}, respectively, essential for the execution flow
description. Item 4 shows the {\sc Action} element, which describes for example
\textit{download music, listen music} and \textit{publish twitter} actions and
finally, item 5 highlights the {\sc Assertion} element, which is used to
describe the restrictions over each {\sc Action}.  
 
\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/implementation/figs/create_model-ServiceProcess.pdf}
\caption{\textit{$\pi$-ServiceProcess} Model Definition in $\pi$SOD-M Eclipse
Plugin.}
\label{fig:piserviceProcessToolModel}
\end{figure} 

The designer must also configure the properties of each
\textit{$\pi$-ServiceProcess} model element for it be expressive enough and
describe all constraints that compose the contracts and the application process.
Figure \ref{fig:piserviceProcessToolModelProperties} presents the properties of
the main model elements. These properties complement
the modeling of the execution flow.
   
\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/implementation/figs/model-ServiceProcess.pdf}
\caption{\textit{$\pi$-ServiceProcess} Properties in $\pi$SOD-M Eclipse Plugin.}
\label{fig:piserviceProcessToolModelProperties}
\end{figure} 

Item 1 in Figure \ref{fig:piserviceProcessToolModelProperties} describes the
properties of a {\sc Fork Node}, which is associated with {\sc Edge Activities}
({\sc Control Flow} and {\sc Object Flow}) that connect the {\sc Action}
elements. For example, the {\sc Fork Node} \textit{fn\_toPublishMusic} has an
input edge (\textit{cf1}) and three output streams edge (\textit{cf2, cf3} and
\textit{cf5}). All these elements are {\sc Control Flow} entities (item 3). Item
2 shows the {\sc Action} properties, and items 4 and 5 describe a {\sc
Contract} and its {\sc Assertions} properties, respectively. A {\sc Contract}
has a \textit{name} and the information of an {\sc Action}.
{\sc Assertions} are {\sc Contract}'s child element. Each  {\sc Contract} can
have many  {\sc Assertions}. Each  {\sc Assertion} has six properties, they are:
(i) \textit{AProperty}, which describes the runtime verification execution time,
(ii) \textit{description}, (iii) \textit{variable name}, (iv and v) a maximum
and minimum allowed to be checked (\textit{MaxValue} and \textit{MinValue}) and
the variable (vi) \textit{type}. In cases of non numeric types, \textit{e.g.}
\textit{Short Int, Flot} and \textit{Double}, only \textit{MinValue} property
value is considered property  and\textit{MaxValue} is described as
\textit{null}.

 
\subsection{\textit{$\pi$-ServiceComposition} Models}

The goal of creating a \textit{$\pi$-ServiceComposition} model is to represent
the system service compositions and to reference the external services
that are call by the application. The designer receives the
\textit{$\pi$-ServiceProcess} model as input to generate the
\textit{$\pi$-ServiceComposition} model. After the
\textit{$\pi$-ServiceComposition} model be generated, the designer calls again
the model transformation component to generate the \textit{$\pi$-PEWS} model as
output (figure \ref{fig:sequenceDiagram}). The output model describes the system
specification in a specific platform. 

To create the \textit{$\pi$-ServiceComposition} model, it is necessary choose
the root object (\textit{Composition Service Model}) as the starting point of modeling,
during the process of create a ``new .piservicecomposition file'' option. From
this point the model is created as a tree with its specific references.

Recall that the \textit{$\pi$-ServiceComposition} model is a refinement of
\textit{$\pi$-ServiceProcess} model, most elements are the same, except for {\sc
Business Collaborator, Policy, Rules} and {\sc Variable}. Thus, we will detail these elements in the
model editor description. Figure \ref{fig:piserviceCompositionToolModel} shows
the relationship of these elements. Each {\sc Action} has an specific {\sc
Business Collaborator} (item 3), this elements express the external service
provider, such as Facebook, Twitter or Bank. Another example of a {\sc Business
Collaborator} definition is a WSDL specification. The WSDL namespaces represents
a kind of {\sc Business Collaborator}. Besides {\sc Business Collaborator}
element, the main children root element (\textit{Composition Service Model})
are: {\sc Policy} and {\sc Service Activity} (item 1), and each {\sc Policy}
(item 2) is directly related with {\sc Service Activities}. From a {\sc Policy}
it is possible to create a set of {\sc Rules} (item 4). Figure
\ref{fig:piserviceCompositionToolModel} also presents a equivalent graphic
model. In this figure, the \textit{Application}'s {\sc Business Collaborator}
presents only the main {\sc Actions} (\textit{buy music, listen music, publish
Facebook} and \textit{publish twitter}) that are related with a {\sc Service
Activities} that have one {\sc Policy}. The \textit{Application}'s {\sc Business
Collaborator} model is the same presented in the previous section
(\textit{$\pi$-ServiceProcess} model).

 
  
\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/implementation/figs/create-model-Serviceconposition.pdf}
\caption{\textit{$\pi$-ServiceComposition} Model Definition in $\pi$SOD-M
Eclipse Plugin.}
\label{fig:piserviceCompositionToolModel}
\end{figure}

The properties of \textit{$\pi$-ServiceComposition} elements are
configured as the same way the other two previous editor, and the properties
the the same described in the \textit{$\pi$-ServiceComposition} meta-model
(Figure \ref{fig:servicecomposition}). Thus, to configure the properties of this model,
it is necessary simply choose the desired element and modify its values.


\subsection{\textit{$\pi$-PEWS} Models}

The goal of creating a \textit{$\pi$-PEWS} model is to represent
the application in a specific platform. The designer receives the
\textit{$\pi$-ServiceComposition} model as input to generate the
\textit{$\pi$-SPEWS} model. After the
\textit{$\pi$-PEWS} model be generated, the designer calls again
the model transformation component to generate the \textit{$\pi$-PEWS}
specification code as output (figure \ref{fig:sequenceDiagram}). This code will
be executed. 
 
To create the \textit{$\pi$-PEWS} model, it is necessary choose the root
object (\textit{PEWS Spec}) as the starting point of modeling,
during the process of create a ``new .pipews file'' option. From
this point the model is created as a tree with its specific references.

The \textit{$\pi$-PEWS} model is a representation of its language. The elements
described in this model represent parts of language's grammar constructs.
Each entity in the model represents a piece of \textit{$\pi$-PEWS} code. Thus, as the
model is being built, seems that it is specifying a \textit{$\pi$-PEWS} program. 
	
\begin{figure}[ht!]
\centering
\includegraphics[width=.90\textwidth]{chapters/implementation/figs/create_model-PEWS.pdf}
\caption{\textit{$\pi$-PEWS} Model Definition in $\pi$SOD-M Eclipse Plugin.} 
\label{fig:piPEWSToolModel}
\end{figure}

Figures \ref{fig:piPEWSToolModel} and \ref{fig:piPEWSToolModelProperties}
show how the \textit{$\pi$-PEWS} model can be designed. However, this model is
generated automatically from the \textit{$\pi$-ServiceComposition} source model.
The properties of each element is described from its meta-model reference and
follows the structure for model edition described in previous sections.     

\begin{figure}[ht!]
\centering
\includegraphics[width=.90\textwidth]{chapters/implementation/figs/create_model-PEWSProperties.pdf}
\caption{\textit{$\pi$-PEWS} Model Properties in $\pi$SOD-M Eclipse Plugin.} 
\label{fig:piPEWSToolModelProperties}
\end{figure}


\textit{$\pi$-PEWS} is the last model generated before the code generation, so
it is possible the designer proceed with a general manual check of consistency before the final
code generation. It's important to highlight that the environment does not
replace completely the modeling work required to design and develop services based
applications. The environment supports the development, however, the final
decision will always be from the designer and software engineer.

\section{Extending the Environment} 
\label{sec:extendingEnvironment}

Both, $\pi$SOD-M environment and methodology can be extended. This extension can
be done in two different levels. The extension can be processed in the most abstract level as
in the lowest level (considering structure presented in Figure
\ref{fig:developmentProcess}). The extension may be given in terms of language.
Meta-models of other languages can be described and coupled to the environment.
The extension process should take place as follows. New languages meta-models
may be modelled and coupled in the environment architecture, such as BPEL, XAML,
WSDL, XLANG and so on. After creating the desired meta-model, a mapping must be done. The mapping must consider the \textit{$\pi$-ServiceComposition} meta-model, and the model
transformation can be proceed correctly. It also necessary describes the rules
for codding generation, using a code generator engine such Acceleo. Thus, new
languages may be added for the environment improvements and for improve the
methodology flexibility. Considering the highest methodology level, new meta-models can be
described in the computing independent level (CIM level),  for example, describe
the requirements and business restrictions in terms of models. Thus, this new
CIM models would replace the requirements specification and
business specification documents for CIM models. 


\begin{figure}[ht!]
\centering
\includegraphics[width=.95\textwidth]{chapters/implementation/figs/componentes.pdf}
\caption{$\pi$SOD-M Environment Extension Components.}
\label{fig:extension}
\end{figure}


 

Figure \ref{fig:extension} presents how the environment can be extended.
The components that can be inserted components of CIM-to-PIM transformation
models (item 1), new languages meta-models description (item 2) and
components which represent the transformations between the
\textit{$\pi$-ServiceComposition} model and each language (item 3). Thus, it is
possible to extend the development environment of SOD-M. The extension must complies with
the methodology concepts and environment architecture.     
 
\section{Conclusion} 

This chapter showed the structure of $\pi$SOD-M methodology environment. It was
presented and described the general environment architecture, its properties,
language used, its execution environment and how to extends the environment. The
development environment of $\pi$SOD-M supports the methodology for a better use of their concept. 

We also presented in this chapter a representation for model description. This
graphical representation can be better refined in future work, which the focus
behalf of processing models, or to develop a visual tool for processing models
and code generation.

Using the proposed graphical nomenclature, we describe all the transformation
rules that were used for the development of the environment's plugin responsible
for the transformation of all $\pi$SOD-M models. This chapter also presented, in
detail, all $\pi$SOD-M meta-model matching of, such as how to extend the
environment and use it. Finally, after the design description, were
introduced the execution environment example for the development each models in
$\pi$SOD-M context.
    